Core Question

Policy 如何辨識 Tool Call 的 side effect、可逆性、資料範圍與 impact，而不只看 Tool 名稱？

今天的問題

同一個 records Tool 同時提供 query、update、delete。只給 Agent records:use scope，PDP 便看不出查詢一筆低敏資料與刪除一萬筆客戶資料的差異。Tool 名稱是路由資訊，不是完整的 Action semantics。

為什麼這不是傳統 IAM 問題

這特別是 Agent 問題：模型可能把「清理重複資料」規劃成 bulk delete，且從前一步查詢結果推導參數。授權必須看 canonical action、批次大小、可逆性、資料敏感度與 Task，而非相信自然語言描述。

Threat / Failure Scenario

Agent 原本只被要求查詢。外部資料誘導它呼叫 delete(records=[...])；allowlist 只檢查 tool=records，因此刪除成功。即使把 delete 列入 deny，若 update 能把狀態改成不可恢復，仍會留下同樣的高 impact。

核心概念

建立可審核的 action taxonomy：read 通常無 side effect；write 會改變狀態；delete 往往不可逆；bulk 依 cardinality 放大 impact；external send 會跨 trust boundary。risk tier 是 policy input，不是模型自己宣告的欄位。高 tier 可以要求更短 TTL、二次 resource check、approval 與更完整 evidence。

可逆性和敏感度也要由 Tool/resource owner 提供可信 metadata，Gateway 對不一致的宣告採較高風險或拒絕。決策結果可為 allow、allow with max_items constraint、approval_required 或 deny。

Architecture Pattern

Naive / Unsafe Design

依 tool name/HTTP method 做單一 allow；將 risk=low 直接接受為 Agent request 的欄位；所有 operation 共用一把 credential 與相同 audit policy。

Recommended Design

Action classifier 從 schema、resource metadata 與已驗證參數產生 risk facts。PDP 同時評估 actor、subject、Task、operation、resource count、sensitivity、reversibility、destination。PEP 在執行前重新計算 digest；結果帶 obligations：例如 query 最多 20 筆，delete 必須 approval。

Trust Boundary

模型和 tool description 只能提出 action；classifier、resource metadata、PDP 與 audit service 位於受信任控制面。Tool 仍需拒絕不符合 resource-level constraint 的請求。

Identity Flow

保留 subject、actor、task_id、operation、resource_set_digest 與 policy_version；高風險 credential audience/TTL 由 Gateway 決定，不由 Agent 自選。

Authorization Decision Point

query 1 item → allow；update 1 item → constrained allow；delete 1 item → approval；bulk delete 10,000 → deny 或 approval + max set。這是 action-level decision，不是 tool-level permission。

小型 PoC

def decision(op, count, reversible, sensitivity):
    if op == "query" and count <= 20: return ("allow", 300)
    if op == "update" and count <= 1: return ("allow", 120)
    if op == "delete" and count == 1 and reversible: return ("approval_required", 60)
    return ("deny", 0)

assert decision("query", 1, True, "low") == ("allow", 300)
assert decision("update", 1, True, "low") == ("allow", 120)
assert decision("delete", 1, True, "high") == ("approval_required", 60)
assert decision("delete", 10000, False, "high") == ("deny", 0)
print("query/update/delete/bulk decisions verified")

今天得到什麼

1. Tool name 不是 action semantics；side effect 必須進入 policy input。
2. 批次規模、可逆性與資料敏感度能改變 decision 和 credential TTL。
3. 高風險 Action 應回傳 approval 或 constraints，不是讓模型自行克制。
4. Action digest 與 execution-time recheck 防止 allow 後偷換參數。

下一篇

Day 20 會處理 approval_required：人要看到哪些確定的 Action facts，核准如何綁定，避免 approve 一件事卻執行另一件事。

參考資料

• NIST SP 800-30 Risk Assessment
• NIST SP 800-53 Rev. 5 Access Enforcement
• NIST SP 800-207 Zero Trust
• RFC 8693 OAuth Token Exchange